perm filename USERS.RLL[RDG,DBL]2 blob
sn#606846 filedate 1981-08-14 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00016 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 See all RLL.BBD[rdg,dbl].
C00004 00003 ∂05-Nov-80 1342 SASTRY at USC-ISIF RLL applications
C00006 00004 Contact with Keirsey@ECL
C00018 00005 UICC's interest
C00034 00006 Messages with Larry Hines - at UofTexas, Austin
C00048 00007 Messages with Steve Klein (ISI)
C00063 00008 (klein, con't)
C00070 00009 (klein, con't)
C00092 00010 (klein, con't)
C00121 00011 (klein, con't)
C00128 00012 (klein, con't)
C00133 00013 ∂TO CSD.SMITH@SCORE (CC SKLEIN@ISIB) 14:37 10-Aug
C00134 00014 RLL Mini-Tutuorial - ca 3-7 August 1981 - Klein, Jonathan King, Greep
C00143 00015 Messages with Jonathan King - HP
C00145 00016 Messages with Steve Tepper (Greep) - Rand, Stanford
C00147 ENDMK
C⊗;
See all RLL.BBD[rdg,dbl].
∂05-Nov-80 1342 SASTRY at USC-ISIF RLL applications
Date: 5 Nov 1980 1330-PST
From: SASTRY at USC-ISIF
Subject: RLL applications
To: greiner at SU-AI
Hi,
I obtained a copy of the paper describing RRL-1. Thankyou. Mentioned in it is
a reference to some work on applications of RLL to VLSI layout. I am also
interested in this although I have not done any real work along this path.
What I would like to know is what problem is being looked at and what has
been done.
Could you send me any info concerning this or direct me as where I amy obtain
such information ?. Thanks again.
Sarma Sastry. (Sastry@USC-ISIF)
-------
Mailed to SASTRY, STEFIK@PARC&HBOWN@SCORE/cc 16:49 5-Nov-80
VLSI/RLL interconnections
Mark Stefik (STEFIK@PARC) and Harold Brown (CSD.HBROWN@SCORE) are
currently building a system which will help plan and design VLSI layout.
(According to Mark, ISI's Danny Cohen knows all about it.)
I sent them a copy of your message.
Russ
Contact with Keirsey@ECL
∂13-Oct-80 1226 TOB
To: ROD, DLO, BIS, SL
Bruce
That's an excellent letter. Thanks for the support.
Tom
∂13-Oct-80 0155 BULLOCK at USC-ECL SAIL/MACLISP image processing software
Date: 13 OCT 1980 0154-PDT
From: BULLOCK at USC-ECL
Subject: SAIL/MACLISP image processing software
To: Druffel at ISI
cc: tob at SAIL, bullock
I have been talking to Tom Binford lately about getting a copy of the
MACLISP based software kernel that he has been developing for image
understanding work. I mentioned to Tom that I would send you a
note letting you know of our interest in using some of the
you have supported.
Put simply, our work has undergone a long process of evolution. In 1973 our
first scene analysis software package was implemented in LISP 1.6 and was
used to support work on rule based control structures for scene analysis
for several years on an AFOSR grant. With the change in funding policy
about that time to emphasize work more directly related to military
applications, the main line of our activity shifted from general system
investigations to applied work on problems like target cueing and image
based terminal navigation. Although I built one system for texture
analysis in SAIL while I was at Stanford during this
period, most of the systems we built from then on were in FORTRAN. The shift
to FORTRAN was more practical than scinentific and had to do with
compatability with funder supported computers and better availability of
programmers. Starting about two years ago there was a new move
towards systems that for the first time were fairly
complex and some were even rule based (again!) at the control level. This
new generation was enough to justify finally dumping FORTRAN and trying
a switch to another language. For a number of resons, Pascal was
chosen. Several systems, including one with a rule based interpreter,
were implemented on both the PDP-10 and on the VAX. For a number of reasons,
some of the most important involving memory management and automatic
garbage collection, Pascal proved to be a poor implementation language both
for image analysis software and rule based systems. This brings us up to
about the current point in time. A number of other languages have been
evaluated. For straight image processing one of the best seems to be "C".
The situation is now more complex however, because for the first time
we are planning the construction of systems that have a much greater
demand for rule based/kbs components. For example, in the case of
smart weapons this is especially true. Independently of our image based
work we have been using Interlisp for some KBS application studies
envolving EMYCIN and some systems of our own. Both folklore and some
experiments of our own have shown that Interlisp is certainly
not the common denominator link between AI/KBS/and IU that one might hope
for. At the same time as our experience with KBS systems such
as EMYCIN has increased and our application interests have become more
specialized and complex we have realized that we will probably have
to do alot of our own system crafting to get
what we really wnat. Thus, except for some of the new tools like RLL,
there is no strong reason to stick with Interlisp if we are not going
to use a canned system
like EMYCIN.
All of this finally brings us to Tom's system. Here it looks like we
can build the type of complex image analysis system we need, with
compatability with rule based systems all in one environment. The kernel
operations in his system will probably allow us to go off in our slightly
different direction of hybrid IU/KBS systems but with a good IU starting
point. Also, unlike 1973 when we were apushing to
keep working in LISP 1.6 with little success, the mood has changed
significantly, as you are well aware. I think we can make (and probably
will) arguments that because of the advancement in LISP implementations
that emphasize efficiency and hardware such as the
LISP machine movements and VHSIC technology that it is also "practical"
for us to consider a major reorientation and emphasis to LISP based
software.
So, to bring this long story to a close. For the many
reasons outlined above, we are seriously interested in a LISP based
system for our future work. At the same time Tom's system looks to
have excellent ppossibilities
for what we want. The implementation looks to be one of the best, system-wise,
around and the results from his work based on the software are very impressive.
We have expressed our interest to Tom and look forward to acquiring the
parts of his system that would be needed for our work. If such a transfer
is successful, I will keep you posted of our progress. We will also
be happy to acknowledge the source of the kernel in terms of Tom,
Stanford, and DARPA.
Bruce Bullock.
-------
∂10-Nov-80 1401 KEIRSEY at USC-ECL Details
Date: 10 NOV 1980 1401-PST
From: KEIRSEY at USC-ECL
Subject: Details
To: RDG at SAIL
cc: keirsey
I have read your paper on the Details of RLL. On the whole I thought
it was good. Unfortunately, I had the naive notion that RLL-1 would be
simpler in conception and implementation. As I read it, I got a feel
for how you represented some things, but it is clear to me that real
understanding of a particular knowledge base will only come through
use. One important issue to me is how one can understand another
person's knowledge base (given that they are large). Do you have any
thoughts on this?
I have a very detailed question. On Diagram 1 of Details of RLL, what
is the significance of the AND-node notation (AnyConcreteThing&Unit,
AnySlot)?
-------
Mailed to Keirsey@ECL 17:37 11-Nov-80
Possible Answers
First, to answer the easy question:
In general the subclasses form a DAG, as opposed to a tree.
The "AND-notation" you asked about means that those particular subclasses
are disjoint.
As to your other inquiries:
You are correct in expecting the ideas of a rll to be simple.
The document you received described a particular implementation, slanted
towards things which I thought were relevant. Furthermore, many of the
details presented reflected facets which seemed
appropriate a while back; and which have not yet been updated to a better,
cleaner form.
Prof Genesereth, in writing up his description of MRS
has stressed the simplity of its design. I recommend that paper
(HPP-80-24) to confirm the accuracy of your intuitions.
Yes, Prof Lenat & I have worried quite a bit about the question of how
to insure that each KB is understandable and unambiguous.
We considered using a predefined formal specification,
(such as predicate calculus),
and rejected these as too hard to understand, and not perspicious enough.
The sub-section 4.4 of the AAAI paper (on pages 167-168) describes another
approach - using a "Semantics" slot for each slot-unit, telling what this
slot "really" means. The "Meta-Description & Modifiability" memo (HPP-80-18)
by Lenat & Genesereth, elaborates these ideas.
If this doesn't answer your questions, let me know and I'll try again.
Russ
UICC's interest
Mailed to THORPE@CMUA 13:58 31-Oct-80
U of I @ CC
Jack Mostow suggested you might be able to answer a question I have about
the University of Illinois at Chicago Circle. Is it on any computer
network? In particular, is it on any of the networks which (you know to)
include Stanford - such as the ARPAnet, or SUMEX. (I checked out the
ARPAnet, but could not find it there - does it have perhaps some cryptic
designator?)
Thank you.
Russ Greiner
(I am trying to send a message to Prof Minkowycz and A. Sharma.)
∂31-Oct-80 1518 Charles.Thorpe at CMU-10A (C410CT60) Re: U of I @ CC
Date: 31 October 1980 1750-EST (Friday)
From: Charles.Thorpe at CMU-10A (C410CT60)
To: Russell Greiner <RDG at SU-AI>
Subject: Re: U of I @ CC
In-Reply-To: Russell Greiner's message of 31 Oct 80 16:58-EST
Message-Id: <31Oct80 175047 CT60@CMU-10A>
The only Chicago organization I could get to admit to having ARPAnet connections
was Argonne National Labs, and they're a long ways away from Circle campus. I
don't know about the other nets. Sorry I couldn't be of more help.
Chuck Thorpe
PS--greet Jack for me.
Mailed to THORPE@CMUA 15:50 31-Oct
Thanks anyway.
Do you know anything about the research Minkowycz et al are pursuing?
Russ
∂01-Nov-80 1210 Charles.Thorpe at CMU-10A (C410CT60) Re: Thanks anyway.
Date: 1 November 1980 1507-EST (Saturday)
From: Charles.Thorpe at CMU-10A (C410CT60)
To: Russell Greiner <RDG at SU-AI>
Subject: Re: Thanks anyway.
In-Reply-To: Russell Greiner's message of 31 Oct 80 18:50-EST
Message-Id: <01Nov80 150726 CT60@CMU-10A>
Sorry, I don't know anything about Minkowycz. My only dealings with the U of
Chicago were in trying to get an ARPA link to CMU; I never actually attended
there.
Chuck
Mailed to THORPE@CMUA 13:13 1-Nov
OK
Oh, Jack wasn't sure what your affiliation with UofI@CC was.
Russ
!Mailed (by Post Office) 3 November
1 November 1980
Professor W.J. Minkowycz
Dr. A. Sharma
University of Illinois at Chicago Circle
College of Engineering
Box 4348
Chicago, Illinois 90980
Dear Sirs:
I am pleased to learn of your interest in the RLL-1 system, as expressed
in your letter of 10 October. I am sending, under seperate cover, the
memos you (explicitly) requested, together with two other potentially
relevant ones. The "Details of RLL-1" report includes many low-level
specifics of our current system.
While we do plan to release RLL-1 eventually, we are cautious about
releasing it too soon. Our reasons stem from various causes:
(1) The particulars of the starting RLL-1 system (i.e the "bootstrap") are
still being hammered out. The difficulties of this design are in two
camps: First we want the system to be as unbiased as possible. Given
that this starting system will necesarily employ some conventions we want
to insure each such convention is "minimal" and necessary -- that is, they
should not force you, the user, into difficult situations or awkward
coding. The neo-natal MRS (described in more detail below) is much closer
to realizing this goal that RLL-1 will ever be.
Secondly, RLL-1 should come equipped with enought powerful, general
constructs that the user can readily do a great many useful things, over a
wide range of tasks. Bifucating again, many of RLL-1 current components
have not yet reached the generality we think possible, and furthermore,
there are many areas which have not even been considered, and so the
modules capable of performing this type of task have not yet been built.
This is not surprising: By design, RLL-1 is a continuously growing and
evolving system -- one capable of adding on new components as the need
arises. The concern here is the large number of known ommissions.
(2) Another major problem is the bugs which are present in the current
RLL-1 system. We feel it will take about a month to correct the ones we
now know about.
(3) The other major issue stems from research directions. Prof Lenat and
I developed RLL-1 as a tool, to be used to build the EURISKO system. [See
Appendix B.2 for an overview of RLL-1's role as foundation for this
system. There were two major reasons why we encouraged others to use
RLL-1: First, these other applications will push on the set of features
RLL-1 will have to provide; the modules built to handle such situations
will expand RLL-1's capabilites, making it a more general tool for our
uses as well. Second, RLL-1 will provide a Lingua Franca for
EURISKO-related knowledge bases. To function, the EURISKO system must
first include a large collection of diverse knowledge bases. Rather than
inputing these ourselves, we would rather develope a symbiotic relation
with other researchers -- they will be given the underlying EURISKO
system, as a particular representational/control scheme for their data,
and in exchange, we get to peak over their shoulders, and collect their
set of heuristics. As such, it is strongly in our interest to continue
supporting EURISKO. We have further decided to support/improve RLL-1 only
where such modifications are crucial to its application to this primary
line of research -- which is concerned more with heuristics than with
representations, per se.
The research ideas of a representation language language are still being
pursued here at Stanford, by Professor Micheal Genesereth and David Smith.
They are now developing the MRS (for Modifiable Representation System)
mentioned above. They have guaranteed continued support of its kernel,
and intend to soon develop a full user community, in which implementations
of diverse representational systems can be coopertively constructed,
collected and dispersed. After the (both conceptual and implementation)
bugs have been purged from both of our respective systems, RLL-1 will
actually be encoded in MRS. At this point RLL-1 will be (viewable as) one
of many "plug-in" modules, which "twiddles" that copy of MRS into a system
which follows a particular set of conventions.
With these caveats in mind, here are the options for using RLL-1, as I see
them:
(1) We could export to you the RLL-1 system, as it is now. We would, of
course, make no commitment to support this pre-release version. It is,
however, thoroughly documented, and does do a great number of things
correctly.
(2) In about another month (after removing those major known bugs) we plan
to freeze the then-existent system. This system will be fairly static --
the only updates will be repairs to bugs subsequently found, as opposed to
extensions. Note that we will fix just those problems which seem to lie
on our critical path.
(3) The EURISKO network is just starting up -- within a few months after
getting a working version of RLL-1, we feel it will be distributable. If
your task area is conducive to a EURISKO type of exploration, you will be
welcome to use that system. Recall that this network, which will be built
on top of RLL-1, will continue to be supported from here.
(4) If you wish to pursue representation issues, qua research topic, you
may wish to join the growing RLL-1/MRS community. "Good citizens" of this
group are expected to contribute both ideas and code to an evolving,
improving system.
Let me know which of these options seems most appropriate -- or perhaps
you can envision another possibility.
I have a quick list of remaining issues/questions:
1. Your letter refered to a description of your task. Could you perhaps
send me another copy of this article, as I never found it.
2. Is UofI@CC on any computer network which also includes Stanford? Do
you know of any (even indirect) electronic path from there to here? I can
be reached at RDG@SU-AI, CSD.GREINER@SCORE or GREINER@SUMEX; and much
prefer this faster communication to the slower postal mail.
3. I am enclosing a copy of the first (and only) message posted on the
(Virtual) RLL Bulletin Board. If you wish, I will see that you receive
further messages as well. (Note this bulletin board is intended to
discuss theoretical issues of representation language langauges, as
opposed to our implementation, RLL-1, per se. Notications of
updates/modifications/bugs/etc to RLL-1 will appear elsewhere.)
4. RLL-1, as it now stands, does require InterLisp. MRS, however, will
have parallel implementations in both InterLisp and MacLisp. Thus once
RLL-1 has been written in MRS it will be MacLisp compatible.
This has been the first formal request for RLL-1, from outside of
Stanford. As such the policies concerning how to distribute this system
are quite flexible. If you have any suggestions on how we should
facilitate releasing our system, please let me know. Please let me know,
also, if there is any way I may be of further help with your project.
Sincerely,
Russell Greiner
Computer Science Department
Stanford University
Stanford, CA 94305
CC: Professor Douglas B. Lenat, Professor Micheal R Genesereth, David E
Smith
!∂02-Nov-80 2014 CSD.LENAT at SU-SCORE Re: Comments before I mail this off?
Date: 2 Nov 1980 2011-PST
From: CSD.LENAT at SU-SCORE
Subject: Re: Comments before I mail this off?
To: RDG at SU-AI
In-Reply-To: Your message of 1-Nov-80 1437-PST
An ecellent answer; much bette than I'm sure they're expecting. Thanks.
Doug
-------
!∂05-Nov-80 1020 CSD.SMITH at SU-SCORE Re: FYI
Date: 5 Nov 1980 1017-PST
From: CSD.SMITH at SU-SCORE
Subject: Re: FYI
To: RDG at SU-AI
In-Reply-To: Your message of 4-Nov-80 1806-PST
You should probably ask Ed or Bruce about distribution. I think that Stanford
requires that a copyright notice go out with the software, and may also require
that a liability release form be signed.
-------
Messages with Larry Hines - at UofTexas, Austin
∂06-Apr-81 1939 ATP.HINES at UTEXAS-20 RLL and theorem proving
To: RDG at SU-AI
cc: CSD.LENAT at SU-SCORE
I think that I have finally develop a theorem prover system which will benefit
from being implemented in RLL. However, only a small kernal of the
knowledge base's templates have been created. Other frame types have suggested
themselves and, doubtlessly, eventually even more types will be necessary.
I apologize for having to reask this, but I would like to be able to
<make>
all frames, not marked as permanent, to disappear upon the end of a
session.
Anyway, since I have now finally learned a way to use RLL, I would like
to obtain a copy of it. I am addressable through the APRANET as
ATP.HINES@UTEXAS20 or at least I been told that I am.
larry hines
-------
!∂Mailed to ATP.HINES@UTEXAS-20 (CC DBL) 14:07 13-Apr
Answers, sorta
Larry -
Good to hear from you again. I hope all is well over in Texas.
To answer your questions:
There are several ways to deal with "ephemeral" units, each with its own
set of complications.
Solution 1
Every unit which descends from AnyEphemeral will be wasted at
the end of each session. This is the method I have used for handling such
temporary entities, as it is the safest and most effective.
These wins are not free, though. As you might imagine, closing and writing the
networks will be expensive in time. Furthermore, as these entities are
full-fledged units, creating and initializing each may well take longer
than you'd like. A speed up of, maybe, a factor of 4 or 5 will come about
by judicious use of macros, but there is simply so much work which has to
take place...
Solution 2
You could avoid much of the time-to-close-the-KBs expense by storing
all ephemerons in some garbage KB, which is simply CANCELled at the end of
each session, rather than WRITEten. The problem here is the plethora
of un-updated back-pointers. (IE other units may still point to a now
destroyed temporary unit, causing grief in many situations.) Still, if
you could tolerate this, this solution will be the fastest, and least
cautious.
Solution 3a.
Of course, this is not unsolvable: If you knew which slots might so connect
temporary with permanent units, you could instruct each such slot to
record each connection made; and then quickly map thru these when ending
a session, removing the soon-to-be-offending links.
This will be time-consuming, both during PUTs and when closing things, but
potentially faster than the time loss implied in Soln 1.
Solution 3b
Yet another infinitely-conservative possibility, (along the lines suggested
by Soln 2 above) would be to spend
some time at the start of each session, to remove all offensive links from
the existing units.
----
The decision of which of these is most desirable is where it belongs: in
lap of the user. You the user get to consider what requirements your
task will impose of your system, and build the system accordingly --
ie if you can stand some slop, but prefer your program to be fast,
solution 2 may be best. On the other hand, you may have some idea for
some intermediary system, incorporating some combination of, say 1 and 2
above. Great - as soon as you implement it, it'll be incorporated into RLL
for the next user.
Final note: realize you're not fighting RLL here -- only the specifications
of your task. To permit such flexibility.
RLL never commits itself with respect to temporary units.
-----
Next issue: How to get you on RLL. This is tricky; as RLL is still
(to be kind) buggy. I would have no objection to mailing you a copy
(or actually, permitting you to FTP it), but realize there are many things
which will not work, and there are many remaining holes.
Let me what I can do for you.
Russ
PS I've sent you (ATP.HINES@UTEXAX) several messages, earlier in the year.
(About your SCORE account, and the RLL bulletin board, ...)
Did any other them get thru?
!∂16-Apr-81 0131 ATP.HINES at UTEXAS-20 Getting RLL,etc.
Greetings Russ,
All is well. At least as far as I can tell, it is.
It's the same with you, I hope.
Thanks for the advice on "ephemeral" units. My initial guess is that
solution 2 (i.e. garbage KB) is what I'll use; although, AnyEphemeral units
will probably be required, too.
I don't have a major preference as to which way (FTPing or mailing)
RLL uses to get here. If I FTPed RLL it is likely that I would get it
sooner and be easiest on you. I was wondering how much space RLL takes.
About your messages to me in Sept., I did get them all (I think) albeit
belately. If the RLL bboard is still active, I would like to be on it, if
that is possible.
By the way, say hi to the bozos from the texas boy.
-- larry
!∂Mailed to Hines (CC DBL, DE2) 15:51 24-Apr
Undaunted, into the fray
Glad to see you're still interested. The current version of RLL is now on
Rand-AI's machine. (One fringe benefit of consulting there was unlimited
access to that marvelously unloaded machine.)
As usual, RLL is a mere epsilon increment away from respectibility, and
hence releasability. (I'm now twiddling with MACROs, which, I hope, will
speed up its operations a good order of magnitude.)
Its outward appearance hasn't changed much since last summer; that's
pretty much by conscious design. It has absorbed a fair number of modules
-- mostly concerned with EURISKO, and encoding information about LISP
functions.
Space...
First, RLL is dependent on CORLL, which takes up a fair amount of space.
You may wish to store a CORLL sysout on some public directory -- not only
does this permit others to use this reasonably well documented, (and
possibly useful) tool, but it also spares you from absorbing the cost of
this disk space. Anyway, this will consume about 300-400 pages.
Now for RLL: There are currently several essential KBs, each of which
contains a *.KB file, plus an optional *.. and *.COM pair of files for the
associated LISP functions. Just in static storage requirements, these
will cost about 600 pages. Your dynamic storage should be almost this
much again, for the *.PAGE temporary files. (Note you may not have to
worry about this... In fact, there are only a few cases when it makes any
differences:
(1) if you're system is as stingy as SCORE, which does not permit you any
storage over your allocation, even for an instant; or (2) if you want to
preserve your state using a SYSOUT, in which case you'll have to store
these "temporary files" from one day to the next. In the latter case you
will need not only the 4 to 5 hundred pages for the PAGE files, but an
additional 300 pages for the actual sysout as well.
The figures above refer only to the nucleus required for RLL to run. You
may, in addition, want to utilize other existant KBs -- and of course this
will cost you space. Of course, you will be creating your own "theorem
proving" KBs as well. I have no real idea how much space this will
require -- except to say that whatever you estimate now, I can state from
experience, will not be enough.
Politics and Policies ...
I've got no objections to handing over RLL, as it stands now. There are
some caveats: As I've mentioned before, it's got its share of bugs and
problems; and I've no yen to fix them twice. Which leads to problems: who
will maintain your version? How should I communicate the errors and fixes
found? Perhaps I could periodically mail over new versions of the nuclear
files -- but that would force you to reconnect the units of your nascent
KBs to these time and again. That may just amount to running the
"reconnecting" code each time - which is easy to do, if time consuming.
Of course that may not work. There is a mechanism for sending along
single now-fixed units... maybe that's what I should do? Comments? (Now
is a good time for me to resolve this issue, as I've been promising to
release this system for months now...)
The other issue is Stanford. Nobody here minds releasing the software;
but there seems some worry that you might make a buck on it, and not give
Stanford its share. Sooo, I got a little form I have to have you fill
out.
Comments, critiques, indications of disgust?
Russ
!∂01-May-81 1743 ATP.HINES at UTEXAS-20 daunted, into the fray
Gee, the fray is big.
Well it seems that at the present time finding the space that RLL needs is
not going to happen. At least until out system is augmented by a couple more
disk packs (about four months + delivery delay time from now), I am not going
have a home for RLL.
Gee, even the best laid plans ... .
As I'm sure you know, Doug Lenat will be here Monday so I'll speak to
him on this.
larry
-------
Messages with Steve Klein (ISI)
∂14 Oct 1980 1323-PDT Steve Klein <SKLEIN at USC-ISIB> Re: minor details...
To: CSD.GREINER at SU-SCORE
Hmm...replies 12 levels deep seem to lose the flavor of their contents. wrt
manual 1 vs manual 2, we would like to attempt "hands-on" type experience--
have you set up some mechanism for this? That is, distribution of the system
or use there or ?? (is this info included in your documentation?). If not too
late, I'd like to request two sets of the manuals--I'm trying to shove things
at several people...
Steve.
-------
∂14 Oct 1980 1547-PDT CSD.GREINER Re: minor details...
To: SKLEIN at USC-ISIB
cc: csd.greiner
RLL-1 is fairly close to being distributable. I've not released it yet as it
is still strewn with bugs and inconsistencies. There is also some legal hassles
to be resolved - forms to sign and the like.
In the long term, the MRS system, by Genesereth & Smith, will be the official
bona fide Representation Language Language -- Mike claims it will be available,
sans bells and whistles (i.e. lacking any useful facility) some time in the next
few weeks. RLL-1 will thenafter be encoded in this system, for compatability
and transportability.
I'll try to get you two sets of the manuals. Ask again if you don't
get both sets.
God bless, and too-da-loo,
Russ
-------
∂22 Oct 1980 1509-PDT Steve Klein <SKLEIN at USC-ISIB> I see a ship on the horizon...
To: CSD⊗.Greiner at SU-SCORE
Hi. Do you know which address got used for mailing the memos out? Nothing
seems to have shown up here yet.
Steve.
-------
∂23 Oct 1980 2030-PDT CSD.GREINER Re: I see a ship on the horizon...
To: SKLEIN at USC-ISIB, CSD⊗.Greiner
In-Reply-To: Your message of 22-Oct-80 1509-PDT
Turns out only 25 memos have been sent out so far. The rest (including,
apparently yours) will be sent soon (after the next batch come back from the
printer...)
Russ
-------
∂28 Oct 1980 1407-PST Steve Klein <SKLEIN at USC-ISIB> paper snow
To: CSD⊗.Greiner at SU-SCORE
Hi. Sorry for the bother, but the RLL-1 paper arrived yesterday, without
the "Details..." paper. Could this be due to paper snarl/printing details,
or am I being over-anxious?
wit regardlets,
Steve.
-------
∂TO SKLEIN@USC-ISIB 14:05 3-Nov
Tap tap tap <yawn> tap tap tap ...
Steve - have they arrived yet? (By now they REALLY should have...)
Also, if its not too much bother, please send comments to RDG@SAIL.
Anything interesting happening there?
Russ
∂04-Nov-80 1324 Steve Klein <SKLEIN at USC-ISIB> Re: Tap tap tap <yawn> tap tap tap ...
To: RDG at SU-AI
greetzings. I haven't seen the innards paper yet...murphy's law or the US
mail has achieved self-awareness and is practicing selectivity. Everything
here is mostly mundane...I wonder what the secret is to getting more done in
less time (if you find out, maybe we could bottle it). If Reagan wins I might
move to New Zealand--have you considered what you will do?
A foobar cocktail in your general direction.
Steve.
-------
∂07-Nov-80 2114 Steve Klein <SKLEIN at USC-ISIB> pretty pictures
To: RDG at SU-AI
Howdy...just a quick note: I got the memos yesterday. Thankks.
Onwards.
Steve.
-------
∂05-Nov-80 1051 PRESSBURGER at SCI-ICS
To: rdg at su-ai
Date: Tuesday, 4 November 1980 15:29-PST
From: Steve Klein <SKLEIN at USC-ISIB>
To: PRESSBURGER at SCI-ICS
Re: delta
How does an elephant dance? Music experiments from the point of an
expected sound or just manipulating the equipment...tape decks and loops
are notoriously limited in flexibility...the world needs some decent
computer based composition systems...sounds like a reasonable life/business/
phd thesis. The notion of "knowing" what defines a proof, what a proof
entails, and the underlying knowledge that supports the notion of proof
seems one of the hairier issues I've seen in a while, although I seem to
recall that a major part of (some) philosophical garbage deals with this
in a very ad hoc manner...I haven't read any of Lenats new stuff, so can't
comment on its limitations. Did you see any of the interviews with
"people on the street" last night? Goddamn parrots...is everyone in the
world so stupid that they believe the stuff they see on TV? If I hear one
more person say that "its time for a change" I'll amputate them at the knee.
I hope you kept your senses and didn't vote for Anderson. The "video
revolution" hopefully is the start of the downfall of our current way of
voting...when anyone can watch what goes on in congress there isn't as much
that you can get away with...not an exclusive club anymore. Voting as
it now stands (pick one of 2/3/...) bears the same relation to expressing
your opinion as X'ing a contract does to understanding it...ten years from
now we may see something different...unfortunately, the media stranglehold
may be even worse--the only bright spot is that current trends are away
from centralized control.
There are some great cassette decks available for cheap now. I bought my
parents a Technics one with solenoid controls, fluorescent peakreading meters,
less wow&flutter than my old Sony, metal tape capability, etc. for $260.
There are an amazing number of decks for $150-300 that are great (need to
use metal tape though to get around lower speed...not very cheap, although
compatible with reel-to-reel tape costs). Sendust heads are reasonable, as
are ferrite...don't know that anyone has really pointed out real differences
in end recording quality...just have to stay away from normal permalloy heads.
45 minutes per side is still a problem, but I'd rather flip cassettes at that
rate than reels at ANY other rate.
Barry actually found that "treasure"--a copper plate under the Colorado St.
Bridge...got $100. from the place having the contest...really stupid set
of clues from an overall point of view (the idiot also made several mistakes).
Sandy is looking in earnest for a place to go back to school...police dept
really getting to her, however, I'm most likely going to stay around here for
the next year or two...interesting contest between too many options and not
wanting to do anything.
Looks like both goodies I'm working on here may potentially end up in RLL/MRS.
Our hardware representation stuff is evolving into general VLSI design (I
think I mentioned that at some point previously)...most of the mechanisms
needed to do this are also common to all engineering design projects--
interesting to see what generalities could result...as I think I also mentioned
previously, one part of this looks just like a part of an automated
programming system or heuristic-based compiler...I'd like to get your
opinions at some point on how you think the world should be organized.
The other stuff will probably be my masters thesis...a computational
framework for systemic grammars (the linguistic underpinnings of SHRDLU,
among other things, if you haven't seen anything on them). For the
multi-paragraph English text generation stuff. End result will hopefully
be nicely enough done that it can be turned on anything in the RLL system
(with appropriate concept-to-English expression mappings). Such grandiose
plans, sigh.
Steve.
∂Mailed to SKLEIN at USC-ISIB 18:13 9-March
... and you were about to give up ...
Steve -
Rejoice, rejoice, rejoice! The MRS manual has gone to press, errors and
all. All 35 pages will be mailed to you when it becomes available.
If you like I'll carry a copy thence 18-March.
I've a now-more-official-than-last-time-invitation to arrange to consult
at Rand, scheduled for 19-20 March. Would you like to get together sometime
around then?
Russ
∂09-Mar-81 1822 Steve Klein <SKLEIN at USC-ISIB> Re: ... and you were about to give up ...
Truly amazing...if you brought down a copy I wouldn't complain. Doing
something/whatever sounds reasonable if it doesn't conflict with your (any)
plans. I don't think I have any problems in that respect. I'll check and
get back to you.
Steve.
-------
∂30-Mar-81 1831 Steve Klein <SKLEIN at USC-ISIB> ..oops..
To: RDG at SU-AI
I seem to have misplaced the fact that you were coming this-a-way. Oh, well...
how was you trip/consulting experience (assuming it occured)? What's new
up your way...anyone you know poke holes in our "illustrious leader"?
Steve.
-------
∂Mailed to SKEIN@USC-ISIB 14:30 31-Mar
Yak, Yak, Yak
The trip was good, if tiring.
The stuff at Rand looks financially rewarding, but not (yet) intellectually
stimulating. I saw Fay and Bonnie whilst there, as well as 4/5 of my nuclear
family (yawn).
So how's by you? You'll be overjoyed to know that at this very moment
(yes, right now!) your personal (almost autographed)
copy of the MRS manual is meandering its way to your clutches --
really!
I was waiting for Mike to mail you a copy; and he assumed I was playing
postman. Anyway, enjoy. (It's not all that interesting, but you'll find
that out soon enough...)
Russ
(klein, con't)
∂06-Apr-81 1612 Steve Klein <SKLEIN at USC-ISIB> Re: Yak, Yak, Yak
<<<< ∂Mailed to Steve (CC Mike) 11:14 8-Apr >>>>
Answers, such as they are
Hi. Sorry about the delay. I got the paper the day after your message.
Thanks. It is rather sparse stuff. Have any of you written down a "game plan"
of any sorts? The following (for example) are of most interest:
*****
Game plan: Mike has a vast list of things he hopes MRS will be able to do,
one day. Included are such diverse elements as {fear, surprise, ruthless
efficient and an...} preservations of invariants, proliferation of demons,
graceful agenda-driven process-interruption and -resumption, ... Ask him
for the full list. (He, of course, wouldn't give it to you, but you can
at least annoy him with another reasonable request...)
*****
> The relation between RLL and MRS, both short and long term
*****
RLL vs MRS: Currently these are two distinct systems, each sitting on the
same CORLL foundation. That's the way tey'll stay in the short term; eventually
I/we hope to find some slave labor to incorporate RLL into MRS, by making
an RLL-initializing module, which can be plugged into MRS's core. (Volunteers?..)
For what it's worth, some Xerox people (led by your hero and mine, Mark Stefik
[isn't it annoying how many mono-syllabic, quadra-epistle male moniker there
are -- and they (we?) all seem working on this silly set of projects. Any, back
to the plot:]) began with MRS, but grew dissatisfied; with its code itself,
as best I can tell. So begot LRS (for Little Representation System; cutely
sandwiched between Krs and Mrs, alphabetically.) And so much for our maxim,
of halting the proliferation of similar but incompatible ...
*****
> RLL/MRS's place in the structure of things at Stanford (support, interest,
again long term expectations)
*****
Place in the sun: as long as either Lenat (hereafter DBL) or I am around there
will probably be continued interest in RLL;
ditto for MRG (an alias of Mike Genesereth) with respect to MRS.
As MRG has suckered slews of naive personel into using MRS, it will probably
even be supported for a while, whatever that means. The Rand stuff will
keep me honest, wrt RLL.
DBL is currently EURISKOing in virgin LISP, by the way. Eventually he hopes
to do the stuff in RLL, but thus far has found its time requirements too
stringent...
*****
> Status of RLL examples (Hearsay-type, KLONE, etc.)--someone doing
something, waiting for volunteers, etc.
*****
<This answer is as sparse as the work done, except for meta-comments,
(and, of course, that last Meta-Meta-Comment [whoops, and that last
Meta-Meta-Meta-Comment {not to mention the preceding ....}]).>
I left the above part in to be cute - but actually I have found the need to
build up features of the Units package -- esp its inheritance (SPECS) relation,
of gradual refinement.
*****
> Any urges to build general "real-world" type knowledge bases/rep-
resentations (time {gak}, spatial location, events, general taxonomies)
*****
In EURISKO's eventualities, (or at least in DBL's conception of it,)
vast amounts of common sense will be available to this over system;
and this body of facts, heuristics, ... will grow daily, due to both
input from various users, and EURISKO's introspective capabilities.
A paper I started to write an IJCAI paper a while back,
"spontaneously aborted" itself when it became apparent the poor
thing lacked anything which did more than resemble semantic content.
Its intent was to discuss EURISKO itself, and these issues, perhaps.
Anyway DBL and I may one day massage it into a reasonable shape.
If so I'll be able to suitable answer that question with a pointer to that
piece of paper.
*****
> Mailing list / users group status
*****
I'm not sure what you want here. Yes, there is a degenerate mailing list,
consisting of people I feel should get this sort of stuff, including you,
Tom, and Rick H-R. Nobody from outside has contributed, yet.
*****
If you guys haven't formulated such "positions" yet, feel free to ignore.
We are finally getting down to a particular representation for the knowledge
delivery / text generation project (generally KLONE-like) and it would be
truly wasteful to generate another hack system (especially when a specific
goal is exportability). Enjoy.
Steve.
-------
(klein, con't)
∂21-Apr-81 1732 Steve Klein <SKLEIN at USC-ISIB> Sunshine and Light
To: RDG at SU-AI
Somehow, MM asking (demanding) that I title everything is ridiculous (hmm...
I've never seen whether the Subject field goes away if blank...probably not).
Anywho, in the process of "selling" RLL to the powers-that-be the need that
emerges is for more toys to show. What could I actually get my hands on
(*.exe, KB's, other unit descriptions, demos, random prose, ...), with what
restrictions? We have an immediate need for something which shows handling of
events and event sequences (presumably the chemical spill type goodies, if
they still exist). The gospel seems to be potent...no one has complained yet.
Have you written your anti-reagan letter for the day?
Steve.
-------
∂Mailed to SKLEIN 16:02 22-Apr
Thunderclods and Darkness
Hmm - to answer the easy question: yes, MM does NOT force you to en-subject
your messages. Now for the hard stuff:
I'm elated the "word according to the prophet Steve" is so catchy.
I'm not quite sure how to go from here; what would best further RLL's cause.
The code still has bugs in it -- so what else is new?
Its external appearance hasn't changed much
over the last n months -- unless you pull out your stop watch and observe
it cruising along at many times the speed it once had.
(That is, the amount of speed has increased; not the time spent for
a given task.)
My next step will further speed up the system -- making several functions
(like GetValue) macros; so the compiled code will be able to avoid dozens
of costly queries.
After that I'll code up a Units-like SPEC relation (gradual refinement),
which seems essential for a wide variety of tasks. (Not only for the
SPILL stuff, but also for Rand's planner system; and from your description,
for your stuff as well.)
Let me ask this: does ISI have some (competent) manpower (well, person power)
which could be contributed towards the greater good of ...
There are a host of simple-ish chores which just take someone to sit
down and do it; and I've been unable to get any of the BS or MS students
sent my way up to speed. Hence RLL's incompleteness.
And hence my reluctance to send a flawed copy ISI-bound.
Let me know. Any messages for these parts -- eg to Tom, or ? ?
Did you know that Jon Nimitz is in India now?
And what's this anti-Raygun stuff? I mean, really, he's our president!
Mr Yankee-Doodle himself! (Forgive me, I have to get in the spirit.
Rand's putting thru a security clearance on me now.)
Mom and Apple Pie! My country 'tis of thee..
Russ
∂22-Apr-81 1701 Steve Klein <SKLEIN at USC-ISIB> Re: Thunderclods and Darkness
Thunderclods only happen after bombing runs (to not witness would I like).
What is Nimitz doing in India? Say hi to the world up there where appropriate
(when in doubt laze [for to refer to the instances of being lazy]). Ignoring
your seekurity clearance aspirations for the moment (if they come by here will
I have stories to tell [rasp, rasp {as in the sound of dry hands colliding
torsion-wise}]) for what is a president except possibly someone to throw
mud-pies at? Unfortunately, our cheap executive seems intent on not honoring
that tradition of silent clodhood, but insists on being a vocal clod (isn't
that poetic?). By even suggesting otherwise (this is for rhetorical effect)
you are supporting the infidels (incidents of complaints concerning book
contents [censorship-wise] are up five-fold since January...).
Current status of things here (RLL) is that superiors consider it a good
tool from which to learn how to design OUR representations (aaaaargh!!!!).
The battle being fought is one of convincing that much time would be saved
by USING it in our plans rather than treating it as a model. If that could
be accomplished, the three-to-five of us would (presumably) put time into
upgrading/fixing things as well as developing our own extensions (or trash,
depending on how things go...). Consequently, the need is for AMMO to point
out that starting from scratch is a waste of time. Anything I get from
you now need have no guaranteed status, but the directions in which things
have been extended (actions, control, "world"-knowledge) are important.
It's basically a selling situation with the other details to come later...
Steve.
-------
∂Mailed to SLKLEIN@ISIB 16:03 24-Apr
Answers, maybe...
Nimitz: Story, according to Bonnie, is: some broad juilted(sp) him, so
its off to the peace core (for want of a nearer French Foreign Legion).
SC: Nah, THEY wouldn't trouble you. Tom's on their list, but ...
RLL, and friends: Well, the fact of the matter is RLL 'tain't yet
releasable; and even when it is I've got no real yen to maintain it.
In terms of Ammo (I kept trying to figure out what it was an acronym for...)
well, RLL does do Slots real good. And soon will do general functions
as nicely. What sort of demo would you like?
Would verbal contact be better than written?
Have you seriously considered MRS as a nucleus? Why or why not?
Russ
∂24-Apr-81 1631 Steve Klein <SKLEIN at USC-ISIB> Re: Answers, maybe...
A nice subject title...if you make them general enough they are reusable
without indirection.
Our current view of "our" representation is based somewhat on KLONE...
intensional concepts vs. extensional individuals, roles with specifications
(for each role instance) of cardinality & value restrictions, one or more
inheritance mechanisms, etc., etc..... It seems closer to the base state
of RLL than MRS. If you don't see this as true, feel free to enlighten me.
Steve.
(Maintenance only exists if the assumption is that something is being
maintained)
-------
∂Mailed to SKLEIN 16:49 24-Apr
Idea:
Why don't you make up a list of things you want to represent, as well
as the sorts of inferencing/retrieval algorithm you need.
Send these (your tired, your huddled, your yearning masses ...
oops - you mean you're not from the security office? Never mind.)
over, and I'll try to cons up a RLL-ish encoding. (I did this for
a set of some 20+ "facts" after the Expert Systems conference, which
I could mail you -- or have I done that already?)
The powers that be can likewise draw up their idealized KL1ish representations;
and then compare the results.
By the way, I do think your assessment of MRS is apt: it ain't got as many
goodies as RLL's got. This is true both when comparing base states,
and sum total of available (respective) systems.
If you were to get RLL, how would I communicate fixes/updates/improvements
to you; and vice versa? This is what I meant by maintenance.
Ta-taa
Russ
!∂24-Apr-81 2329 Steve Klein <SKLEIN at USC-ISIB> Re: Idea:
I haven't seen the results of the Expert Systems conf...i'll read anything
(once). The powers-that-be are laboring under the viewpoint that there is
nothing wrong with casting things in concrete as long as you have a vague
idea of what you want. I'm arguing towards ABSOLUTE (nice to be firm)
generality since we need to represent such things as events & event sequences,
times & time intervals, hypothetical circumstances, not to mention several
funny control regimes (assuming everything fits together) and who knows what
else...
I could (and will) send you a sample of the "hand-waving" level of stuff we
now have, along with the pseudo-strange properties it has. If I can be
convincing to everyone else at this level then it doesn't matter that any
future flexibility is achieved (that comes for free). People here are
not sure that the RLL approach to things buys them anything ("excess
generality...we don't need any of that..." type comments).
wrt maintenance, that is a standard hairy area & depends upon whether such
goodies are flowing both directions or not. At an initial level, there
presumably need be no effort on the part of you people beyond answering
questions (our responsibility to snarf most-recent versions, keep our changes
modular, etc.). The first problem occurs if we do "contract" debugging (ala
your previous msg) and you would like to get the fixes back. The final level
of involvement would try to integrate what we do with what you do which could
conceivably be worse than the interaction problems the KRL-types mentioned
(since here we are talking about two totally independent systems). I don't
know what your thoughts are on reasonable levels of interaction and benefit to
your goals up there. I don't suppose our munging on your machine would be
politically feasible...
Steve.
-------
Mailed p11 of REPORT[rdg,dbl] to SKLEIN 12:50 25-Apr-81
!∂29-Apr-81 1042 Steve Klein <SKLEIN at USC-ISIB> for to collect facts...
Date: 29 Apr 1981 1042-PDT
From: Steve Klein <SKLEIN at USC-ISIB>
Subject: for to collect facts...
To: RDG at SU-AI
greets...may your happinesses be daylike, etc...
briefly, how much room is there in the units address space (pages,
max unit limit, whatever) plus how much of interlisps basic address space
is unallocated in a vanilla rll? the question came up and i had not the
slightest idea...
steve.
-------
∂Mailed to SKLEIN 13:11 29-Apr
...stcaf tcelloc ot rof
That's the advantage of CORLL - you can have as many units as you want.
They get swapped in as needed, and swapped out as "core" space demands.
How much space is in "core" initially depends on the version of LISP.
On the Diraldo, who know? and who cares? It's way more than I'll need.
There seems to be less space on SCORE's InterLISP than on Rand-Ai's --
which indicates the disparity amoungst InterLisp implementations.
(IE I can only deduce the two versions start out with different amounts
of unallocated pages.)
The additional "source code" needed to run RLL (beyond CORLL)
is rather distributed:
There are two compiled files - containing general utility stuff
and RLL specific stuff -- of sizes 56 and 38 disk pages, respectively.
The rest is buried in amongst the units.
That answer your question?
Russ
!∂29-Apr-81 2241 Steve Klein <SKLEIN at USC-ISIB> Re: ...stcaf tcelloc ot rof
actually...no. "as many units as you want" is a rather large claim (you
might gather from this that i haven't seen the CORLL manual yet). i bet
you can't make 10 million units, if for no other reason then you can't
have that many pointers in general...do you have a number (1k, 10k, ?)?
the other question is a direct one of if you do a STORAGE] how many free
pages there are, plus roughly how much disappears for each unit (unless
the unit index is paged too)...this all from the tops-20 interlisp point
of view.
Steve
-------
∂Mailed to KLEIN, (CC DE2) 11:17 30-Apr
Partial spec
Limitations will probably be Atom Name size -- as that will probably be
exhausted before the available disk storage is. (CORLL allows units to
be stored on such "peripheral storage" place, rather than "in core".)
Anyway, I now have about a thousand units in use; and have had no problem.
Next time I start up RLL I'll execute the (STORAGE) command.
Russ
!∂30-Apr-81 1734 Steve Klein <SKLEIN at USC-ISIB> what za chanze?
Date: 30 Apr 1981 1734-PDT
From: Steve Klein <SKLEIN at USC-ISIB>
Subject: what za chanze?
To: RDG at SU-AI
What is the chance (he asks nicely) that you could find a copy of the CORLL
manual to zing down this-a-way (or a pointer if online there)? I be much in
your debt given the publication dept's record of achievement...
Steve.
Support National Security (pause) take an MX missile to dinner.
-------
∂Mailed to SKLEIN 15:45 1-May
(Whoooosh)
It's on its way. To answer your question, there is an excellent
chance of finding that manual ...
!∂12-May-81 1556 Steve Klein <SKLEIN at USC-ISIB> regrets or whatever
Date: 12 May 1981 1520-PDT
From: Steve Klein <SKLEIN at USC-ISIB>
Subject: regrets or whatever
To: RDG at SU-AI
Hi. Got your note (thanks for paper)...sorry I didn't call but Sandy's father
has been in for repairs so things have been a bit unusual... Talk at you
later.
Steve.
-------
∂Mailed to SKLEIN 11:46 15-May
Whatever, with or without regrets
No problem - as usual I was overly busy as well. (Among other events
I saw "I Got my act together and am taking it on the road" in Hollywood,
with Bonnie. It wasn't bad; but definately not worth the $. End review.)
Anyway, yes I got that challenge of things to represent; but have not had
the time to sit down and address it. I hope to get to it by next week.
Anything else happening in parts south? Hope Sandy's father's problems weren't
too severe; and that he's better...
Russ
∂15-May-81 1311 Steve Klein <SKLEIN at USC-ISIB> Re: Whatever, with or without regrets
Only the normal wrinkles happening...what to do with my life, etc. Any idea
what you are going to do when you finish your degree? Founding small companies
seems interesting but so does working for other people if interesting and pays
well (concession to real world...). I think Barry and I are going to try
creating something to sell to see how that works...nearly everybody in the
Caltech CS dept is running around pursuing "outside interests".
Sandy's father had a lung tumor (benign) that they hacked out (take heed
smokers of the world...your time will come) but he seems to be coming along
fine.
About time to discover the next place to live (they're selling this one out
from under us)...I hate it...
Steve.
-------
(klein, con't)
∂01-May-81 1745 Steve Klein <SKLEIN at USC-ISIB> A Test of Wizardry
Well...you asked for it...a piece of representation to (potentially) be
encoded in RLL. I hope this isn't too large. Let me know if you find
anything obstructionist or ambiguous.
Have you read any of Levesque's stuff and what you think? The article I've
seen is the one in Findler's Associative Networks book.
Steve.
-----------------------------------------------
Preconditions:
Our general context is the task of text production. The following is meant
as (part of) a representation of the following sentence:
"Jane Doe has cancelled her appointment with us on Wednesday morning."
Conventions:
Things in ALL←CAPITALS are Generic or Individual Concept Names.
Generic Concepts can have subclasses (specified by the SuperC notation).
Generic Concepts can be individuated (specified by the Isa notation).
Individual Concepts represent extensional instances and cannot be
subclassified or individuated.
Concepts can have multiple "parent" concepts.
Things below concepts are Role Specifications, which consist of
a Role Name plus {(Restrictions)} plus a {Role Filler} {} => optional
Concept Names => strictly handles
Role Names => again handles, but inheritable and (perhaps) renamable
(see the VISIT concept below for a rename instance)
Cardinality => single value or <NUMERIC> range of the
<NUMBER OF> role filler(s).
(also, we have been encoding optionality vs.
necessity as a lower bound of 0 or non-0.
It is separable, but must be encoded somehow.)
ValueRestriction => concept which the role filler must be eq to or
descended from.
Role Filler => some concept or set of concepts meeting the applicable
restrictions.
Role specifications are inherited by subconcepts of this concept and their
individuals, ad nauseum, with (some) deepest value taking precedence in
cases of conflict. The deeper specifications must be more restrictive than
their shallower (higher, more generic) ones.
***Generic Concepts***
OBLIGATION SuperC ("SomethingOrOther")
Performer (Cardinality 1:n, ValueRestriction AGENCY)
Beneficiary (Cardinality 1:n, ValueRestriction AGENCY)
Event (Cardinality 1, ValueRestriction ACTION)
APPOINTMENT SuperC (OBLIGATION)
Event (Cardinality 1, ValueRestriction VISIT)
ACTION SuperC ("SomethingOrOther")
Time (Cardinality 1, ValueRestriction TIME←INTERVAL)
Actor (Cardinality 1:n, ValueRestriction AGENCY)
VISIT SuperC (ACTION)
Visitee (Cardinality 1, ValueRestriction LOCABLE←OBJECT)
Visitor (= Actor)
TIME←INTERVAL SuperC ("SomethingOrOther") |
BeginTime (Cardinality 1, ValueRestriction TIME←MOMENT) | lotsa fur.
EndTime (Cardinality 1, ValueRestriction TIME←MOMENT) |
PERSON SuperC (AGENCY)
Sex (Cardinality 1, ValueRestriction SEX)
SEX SuperC ("SomethingOrOther")
***Individual Concepts***
APPOINTMENT#1 Isa (APPOINTMENT)
Performer JANE←DOE#1
Beneficiary ISI
Event EVENT#1
VISIT#1 Isa (VISIT)
Time WEDNESDAY←MORNING#1
Actor JANE←DOE#1
WEDNESDAY←MORNING#1 Isa (TIME←INTERVAL)
JANE←DOE#1 Isa (PERSON)
Sex FEMALE
FEMALE Isa (SEX)
MALE Isa (SEX)
ISI Isa (AGENCY)
-----------------------------------------------------------
Unanswered questions:
The above is a single hierarchy...will this suffice
Where to place inter-role constraints.
What to do with hypotheticality (VISIT#1 above should be a
hypothetical visit <IN THE TIME←INTERVAL "FUTURE">)
Is something lost by role names having significance only for
inheritance
How to support manipulating times, events, objects without
diverse hairy access methods
THE REPRESENTATION HAS TO PROVIDE FOR SEVERAL SETS OF STATUS
MARKS ON THE WHOLE COLLECTION. ALL OF THESE KINDS ARE FOUND ON
BOTH CONCEPTS AND ROLES.
. ONE SET REPRESENTS READER'S KNOWLEDGE OF EXISTENCE: IT
CHANGES INFREQUENTLY AND IS BACKWARDS INHERITED.
. ONE SET REPRESENTS READER'S CURRENT ATTENTION. IT IS NOT
INHERITED.
. ONE SET REPRESENTS WHAT HAS ALREADY BEEN CONVERTED INTO
TEXT BY THE SYSTEM. IT IS NOT INHERITED.>
-------
∂To SKLEIN@ISIB (18:11 20-May)
At long last, the ANSWERS!!! (well, more or less...)
First, my standard meta-comment (I know, I know: that last statement, my
first "real" statement, was really meta-meta-. Anyway,) Rumor has it that
Levesque is heading for Fairchild here in PA, to join Ron Brachman.
Anyway, the above looks amazingly KL-ONEish; and none of it seems even
difficult. The fact that RLL's document implies a disdain for SuperC type
of operators doesn't mean that users can't simply use the existing
SuperSet slot to provide that function. Simply indicating that the
various slots you want inherited are inheritable/specializable seems to
address the final issue. (IE the mechanism for value restriction is all
set up.) Basically the only major change you'd have to made would be
lexical; and using Typicalx to store the defaulted values, over Anyx.
(That is, if you wanted to use RLL as it stands now. Of course you would
be amply welcome to modify (your copy of) the units to correspond to
precisely what you wanted.
Things like storing the cardinality of a "slot" is easy to do in RLL -- it
is stored on the unit which representing that slot (as part of the range
specification). In fact, it can be automatically deduced from the
definition of the slot, in many cases. One more plug -- RLL currently
"knows" about sets, lists and bags (as well as singletons), and permits
you to declare the value of a slot to be any of these data-structures.
Then, when you add on new values, RLL determines, for example, whether the
order of this new insertion makes any difference, or if duplicated entries
are permissible. One may also use the FListN data-structure to specify
the value of some slot to be a list of elements of (possibly) different
types -- eg (FListN UnitType NumberType (FSet BooleanType)) means the
legal values for this slot will be lists of three elements -- where the
first is a unit, the second a number, and the third is a list of booleans.
(The knowledge the knowledge about the datatypes is, of course, stored in
UnitType, NumberType and BooleanType. Let me know if you want more
details about the how this knowledge is stored, or used. Or more about
the way RangeTypes are used... Note finally that this same formalism is
being used to describe arbitrary functions -- not just slots...)
There are many ways of referring to a collection of units. One is to
regard them all as members of class in your hierarchy. (As any unit can
have many parents it may, therefore, belong to several groups -- eg
Reader's Current Attention, as well as its current position in the
organization of the world.)
For this particular example I would not advice that method. First, what
that set of entities have in common is really a meta-relation -- ie its
not John in the Reader's current attention, but the John unit ...
(Assuming I understood your example.) Anyway, there is nothing which
prevents you from defining a RCA units, and a CollectionOfUnits slots,
such that the value of RCA:CollectionOfUnits is just that set of units.
------ As I didn't get a sense of what, exactly, I was supposed to answer,
the above ramblings were just things your example above triggered; and,
undoubtedly didn't answer the questions you had. Do feel free to ask
again, and to constrain my meandering by including more precise inquiries.
Nothing new to report from PA. And there?
Russ
!∂TO SKLEIN@USC-ISIB 16:43 22-June
Answers! (And if you believe that, do I have a bridge for you...)
*-*-* [Step 1: Observe funny squiggles on flush against left margin. Icky, huh?
*-*-* Unfortunately, these are the particular characters I ended up choosing
*-*-* for prefacing my remarks. They are now littered perfusing about the
*-*-* now messy remnants of your last message. Enjoy, as best you can...]
∂17-Jun-81 1639 Steve Klein <SKLEIN at USC-ISIB> Re: At long last, the ANSWERS!!! (well, more or less...)
Hi...got tangled in another part of our project, hence the delay. Anything
new in sight there? Anyways, response to your response.
First, the cardinality of a slot is not the cardinality of a GENERIC slot, but
merely the particular instance associated with this unit/concept. What
this seems to imply is doing something like creating a unit for each instance
of a slot and putting the cardinality/range&type checking stuff there.
*-*-* Yes, this is the sort of thing Doug has been talking about for
*-*-* a while. It is currently not implemented, as I never found a
*-*-* need for this facility. (This might be because I never understood
*-*-* it...)
*-*-* To make sure I understood your example -- do you mean every thing
*-*-* which IsA Obligation, has a performer; and, in fact, it has
*-*-* an nonNIL set of Performers?
*-*-* Should I assume the value of a unit's Performers, for general units,
*-*-* does not have this restriction?
*-*-* Anyway, in every case I dealt with, the
*-*-* cardinality of a slot was invariant... those times I needed
*-*-* to store similar sorts of things with variable formats, I
*-*-* realized I was really talking about two types of things, and
*-*-* as such, they were deserving of distinct slot-names.
*-*-* This was an epistemological distinction, not linguistic ---
*-*-* you certainly may want to use the same NAME for these entities,
*-*-* and trust the system to disambiguate the slot name into the
*-*-* obvious form.
*-*-* For example, declare Performer to be
*-*-* (OneOf ObligationPerformer CircusPerformer),
*-*-* where both ObligationPerformer and CircusPerformer are predefined
*-*-* slots, doing the right things. [In particular, the value of
*-*-* MakeSenseFor(ObligationPerformer) must include TypicalObligation,
*-*-* and MakeSenseFor(CircusPerformer) must include TypicalCircus.]
*-*-* Then the value of Performer(UnitX) will be either
*-*-* ObligationPerformer(UnitX), if UnitX:Isa includes AnyObligation, or
*-*-* CircusPerformer(UnitX), if UnitX:Isa includes AnyCircus.
*-*-* Notice these two subslots of Performer could be totally different;
*-*-* or their only difference may be in their respective formats.
*-*-* (Permitting the value of ObligationPerformer to be a set,
*-*-* while the value of CircusPerformer could be a single atom...)
Ex: Concept Obligation ==> Unit AnyObligation w/
Performer = (*Do* FSeeUnit ObligationPerformer)
and Unit ObligationPerformer w/
Format = NonEmptySet
SuperClass = Performer
*-*-* SuperClass is inappropriate here -- ObligationPerformer, as I
*-*-* understand your example, is NOT a set, but a further specification
*-*-* of a slot. Perhaps you meant "SuperSlot = (Performer)", or
*-*-* maybe "UnitRangeType = AnyPerformer" [<- ie the range of this
*-*-* slot is (FNonEmptySet (UnitType (*P AnyPerformer)))]
etc.
Questions are: does something like this work?
*-*-* Yep, the subslot mechanism, and associated OneOf slot combiner,
*-*-* are now in RLL.
is there a better way?
*-*-* Yes, there is a slightly more natural mechanism (one with less
*-*-* "bulky" and artificial units)
*-*-* for achieving this same results --
*-*-* One simply indicates the ToCompute of Performer is FindDefault,
*-*-* and stores a value of the form (*Do* FExecute (LAMBDA (un) ...)
*-*-* on each TypicalX:Performer which might be queried.
*-*-* I did not mention this above because there are still many details
*-*-* involved that have not been hammered out.
the level of indirection is somewhat disturbing...
*-*-* Why so unsettling? These "subslots" do refer to different things,
*-*-* this formalisms forces you, the creator, to acknowledge this.
*-*-* Of course the casual user need never know about this -- and, in
*-*-* fact, he never has to use these subslots,
*-*-* thanks to that disambiguating facet of RLL's "mini-front end".
Next...could you discourse on inter-slot constraints? Have you built
mechanisms for either enforcing consistency between slot values or signalling
when inconsistencies exist and how do you represent such stuff...note again
that this applies at the instance level (hence doesn't seem to directly
match your type-checking mechanism)
*-*-* At the "generic slot" level, we have just what you need.
*-*-* As you can define the ToPutValue function for any slot,
*-*-* you could incorporate, by hand, any check you think is
*-*-* necessary. Of course, RLL's default mechanism already
*-*-* does a whole lot of these -- basically by replacing "faulty"
*-*-* values with correct ones. [Sketch: Storing V on U:S will cause
*-*-* (i) U to be added to V:S-1, if S-1 = inverse of S exists; and
*-*-* (ii) various W:T's will be "invalidated", where the T slot
*-*-* was built using S. I might mention the PutValue call will return
*-*-* an error condition (here, by returning NIL) if V does not satisfy
*-*-* S's domaintype predicate. [What really happens is a bit more
*-*-* complicated, of course.]]
*-*-* Anyway, it would not be hard to add in another set of things
*-*-* to do when a new value is PUT. As before, I have simply not needed
*-*-* this particular bell/whistle, to explain why this functionality
*-*-* is not present.
*-*-* If you give me a particular case, I can try to either show
*-*-* how RLL already does this; or concoct up a new, hopefully general,
*-*-* mechanism, for achieving that effect.
*-*-* I still haven't said anything about handling this at the instance
*-*-* level. The subslot solution is probably still the "right" way
*-*-* to go. Let me know if you think otherwise.
*-*-* In terms of "represent(ing) such stuff": well, much of what is
*-*-* now done is rather declaritively encoded -- using things like
*-*-* CVsUsedBy and Inverse slots of the units which repesent the slots.
*-*-* (These brief values "expand" into the code which actually does the
*-*-* corpus of work suggested above.)
*-*-* Any other such tests/conditions/constraints you may wish should
*-*-* be similarly encoded.
Also, how are multiple inheritance mechanisms handled? your note seems a
bit sparse in what is actually happening internally to support this.
*-*-* "Inheritance is a many splendored thing."
*-*-* This question probably
*-*-* stems from the different senses of the term we are using.
*-*-* To me, for that report, inheritance mechanisms were used for
*-*-* initializing a new unit. (One of my current tasks is to use
*-*-* some inheritance-like thing in a slightly different sense:
*-*-* to, for example, incrementally specialize a succession of units,
*-*-* ala UNITs.)
*-*-* Anyway, the three current mechanism correspond to:
*-*-* Isa Inheritance: used to create a new Fido, by telling the
*-*-* "procedure" that this new entity Isa AnyDog -- or even that
*-*-* Fido Isa (AnyDog AnyMotleyCreature).
*-*-* SubClass Inheritace: Getting the AnyPoodle class, from AnyDog --
*-*-* or having AnyWhiteElephant:SuperClass = (AnyAlbino AnyElephant).
*-*-* TypicalExample Inheritance: Initializing TypicalDog from AnyDog.
*-*-* These three are just independent things -- and, in some sense,
*-*-* they in no way interfer with each other.
*-*-* Or did your question mean to ask:
*-*-* To what value will Fido:Color be initialized,
*-*-* given that Fido is being created as an Albino Dog?
*-*-* And explain that procedure.
*-*-* (I was afraid of that affirmation.) Ok - honesty: This don't
*-*-* work right. Currently the implementation is far too simple: it
*-*-* will declare Fido to be either the default color for (Typical)Dog,
*-*-* or the default color for (Typical)Albino, whichever it finds
*-*-* first. If anyone pressures me into it, this algorithm could be
*-*-* updated to do some more-nearly-correct type of thing - like check
*-*-* first to see if some characteristic is definitional, and use that
*-*-* before considering any merely assertional fact. Or using some
*-*-* general ordering of property "epistatus" types
*-*-* - from Defination, Derived, Asserted, ... thru
*-*-* Defaulted, and OnlyIfReallyDesperateForAValue-ed.
*-*-* I delayed implementing this until I figured the "right" way to
*-*-* store such epistemological marks on the propoerty; something still
*-*-* on my agenda. (Another less declarative, but more versatile, tack
*-*-* involves storing procedural rules with the ToInitializeValue of
*-*-* slot (eg Color), as well as with each TypicalX:Color. Then some
*-*-* general rule interpreter would walk thru these to determine the
*-*-* initial value. But I didn't do that, either.
--this all looks KL-ONEish as a result of it being derived from it
(abstracted?). Onwards...(scritch, squeal..)
Steve.
-------
*-*-* Anyway, these "answers" were written (probably too) quickly; and may
not have adequately addressed your inquiries. Feel free to write for
further elaboration, if you wish.
*-*-* I forwarded your "let's get together" suggestion to Doug, who may or may
not respond in the near future. He's been busily EURISKOing the last few weeks,
over at Xerox. He's shifted his attention away from RLLish issues sufficiently
long ago that he may not have terribly much to say. But we'll see.
Mike Genesereth would be a good person to join in the discussion, but unfortunately
this meeting will not be in upper Altantic Ocean; and Mike will be, by then.
*-*-* Anyway, I'm game to your strange request to enter a higher bandwidth
communcation -- even though I'm convinced that whole idea of Talking will NEVER
catch on...
I'll let you know when, when I know.
Caio,
Russ
(klein, con't)
∂22-Jun-81 1416 Steve Klein <SKLEIN at USC-ISIB> RLL demo...perhaps
Greets. We will be up your way for the Assoc. of Comp. Linguistics conf.
next weekend until wednesday. Whats the possibility we could get together
with you and Doug for discussions, etc.? If so, could you propose some times?
Meals mon-wed are open as well as sun,tues evenings. Among things it would be
nice to discuss would be specific questions of availability & system
"lifetime" plus perhaps some demo or other. Our complement would be somewhere
between Bill Mann and myself and the whole group of 4/5. Let me know what you
think.
Steve.
-------
∂22-Jun-81 2323 CSD.LENAT at SU-SCORE Re: When would be good for you?
Practically anytime is OK with me. I think next Tuesday
may be best, as I am having a demo for a Schlum. folk then.
(Tha is the 30th I believe) -- somewhere in the lunchtime-2pm range.
Doug
-------
∂23-Jun-81 1304 Steve Klein <SKLEIN at USC-ISIB> Re: How about Tuesday, noon?
To: RDG at SU-AI
cc: Mann at USC-ISIB
Sounds fine. Assuming we include lunch, I'll let you dig up your favorite
PA somewhat-fastfood joint (ACL session time constraints...). Ok?
Steve.
-------
∂23 Jun 1981 2336-PDT CSD.LENAT schedule for Tues
To: csd.greiner
Looks like lunch at the faculty club at noon,
and demo at PARC at 1:30.
How many for lunch?
Doug
-------
∂24 Jun 1981 1723-PDT CSD.LENAT misc
To: csd.greiner
cc: csd.gotelli
Ok, good, Russ. I have worked at the RLL paper a bit
and sent a draft off to Don W.; we will do more around editing time.
Lynn: please make reservations for me, for 4 peoople,
next Tuesday at noon at the Faculty club.
Doug
-------
∂24 Jun 1981 1248-PDT CSD.GREINER Re: Number for lunch
To: CSD.LENAT
cc: CSD.GREINER
In-Reply-To: Your message of 23-Jun-81 2336-PDT
For sure Steve Klein and Bill Mann (in addition to you and me).
There are two or three other ISIers --
but that many more people would probably only slow down our discussion...
So unless you object, let's make reservations for 4. I'll send Steve
a msg tomorrow (ie let me know by then if this is not what you want.)
By the way, Steve and I have sending messages back and forth
since AAAI, discussing RLL. Basically both he and his (still KL-ONEing)
group at ISI are sold on by the rll ideal, and all are toying with the
prospect of using RLL-1 itself.
(Final note: Steve and I know each other from CalTech, years ago.)
Russ
PS Any word on the RLL document for BES? Is it that bad? Or are you just
waiting for the final editing session with (Rick and Don) to splice
it in?
-------
!∂24-Jun-81 1508 Steve Klein <SKLEIN at USC-ISIB> IJCAI
Date: 24 Jun 1981 1457-PDT
From: Steve Klein <SKLEIN at USC-ISIB>
Subject: IJCAI
To: Pressburger at SCI-ICS, RDG at SU-AI
Anyone planning to go to IJCAI / and what means of transportation, timeframe?
Steve.
-------
∂To SKLEIN@ISIB, PRESSBURGER@ISIC (11:40 25-June)
Finally some easy questions to answer!
I'm flying - leaving from SF on 24/VIII (on Western #465),
and then returning on the 30th of August, (on Western #462,) maybe.
(Some friends and I might go camping the week following IJCAI.)
Et tu?
By the way, SCI has been down for about a month -- I think Tom's best
address is @ISIC. (Is that true, Tom?)
Finally, Doug and I are all set to meet with Bill Mann and you at noon
this Tuesday -- the plan is to eat at the faculty club, on campus.
Doug has to give a demo at PARC at 1:30; but I'll be around.
Russ
∂TO LENAT@PARC, CSD.LENAT@SCORE 17:03 29-Jun
Meeting tomorrow
Doug -
I'll see Steve Klein (and I assume Bill Mann as well) at the
ACL meeting tomorrow morning.
We three can meet you at the Faculty Club shortly after noon.
See you then.
Russ
(klein, con't)
∂14 Jul 1981 1516-PDT CSD.GREINER News from ISI
To: csd.lenat
cc: CSD.GREINER
Steve just called me -- he has accepted the challenge, and is set to
immerse himself in the glory and wonderment of RLL. I proposed he
meander here relatively soon -- hopefully while I'm indoctrinating Greep.
So perhaps next week, or the week just thereafter. Is that ok by you?
I'll dig up the forms I have for product release. I guess you and I
should sign the RLL release, and you and Dave the CORLL one -- or are
both necessary?
Next issue: which machine? There are a slew of hassles just switching from
SCORE and Rand-Ai; and I'd rather not be responsible for 3 machines. Should
I encourage Steve to contact Rand, and see if they can give him an account
(which I assume will be difficult, given the hope of the Rand people to keep
Rand-Ai uncluttered), or should Steve get an account on SCORE -- at least
for his training time? Or should RLL sprout a 3rd home?
-----
No news on either the thesis or BES front: My principle text editing
machine is SAIL, which has been flakey of late... So I've been fixing up
some of the RLL-related utilities, and now will get back to finishing
up the Rand task.
------
Any word from Tom Deitterich, or Jim or (who was the third person you were going
to contact)? Also, have you talked anymore with the woman from South Africa?
Russ
∂15 Jul 1981 1153-PDT CSD.LENAT rll news
To: CSD.GREINER
Sounds good; anytime is OK to have Steve up.
I think it best if he works over the net on an ISI machine;
it can't really be that difficult to switch -- just the FTPing
hassles, and you can let HIM be responsible for that -- you just
keep "the latest" version somewhere (Rand or Score) and make
sure he can ftp from that place, and gets notices of new "releases".
Probably he'll just take one semisolid vversion anyway.
Saw Jim and Tom and Avron, and don't know yet who if anyone
will be joining up. Should know soon. Probably NOT Tom,
as he seems fixed upon Dave Smithing it -- doing some
small thing very carefully, theoretically, and properly,
rather than some big thing anyway possible.
Doug
∂TO SKLEIN 11AM 27-Jul
Well....
Steve:
So, when are you hobbling up north? I'm in no particular rush,
but others are:
Some people have been asking about RLL-ish sorts of things, requesting
demos and things like that. I figured I could do that whilst showing
you the system, as that was about to happen any day now. And now they
are starting to show the first signs of impending impatience.
(Can "impatience" be "impending"; or did I just make that up? Sounds good
anyway...)
By the way, would you like to do a bit of propoganda-spreading and
possibly recruiting during that stay? We of HPP have a weekly meeting
at which you could probably speak; if you've the yen, time, interest,
guts, ... The standard time is Friday, at noon. Let me know...
How're things there? In the police hdqrs? At ISI?
I did get your little blurb
Caio,
Russ
∂TO CSD.SMITH@SCORE (CC SKLEIN@ISIB) 14:37 10-Aug
New CORLLer
Dave -
Steve Klein (SKLEIN@ISIB) is now using RLL, and hence CORLL as well.
Could you add him to the list of people whom you inform about each CORLL
fix/update/modification.
Thanks,
Russ
∂10-Aug-81 1524 David E. Smith <CSD.SMITH at SU-SCORE> Re: New CORLLer
I don't have any such list. I also won't be using CORLL anymore and hence
don't intend to do any maintenance on it.
-------
RLL Mini-Tutuorial - ca 3-7 August 1981 - Klein, Jonathan King, Greep
∂27-Jul-81 1736 Steve Klein <SKLEIN at USC-ISIB> Re: Well....
To: RDG at SU-AI
In-Reply-To: Your message of 27-Jul-81 1308-PDT
Sorry. Next week would be ideal. We need a few more days to ready "test
material". I haven't figured out whether I want to end up there Sunday or
Monday yet, though. I decline all propaganda and such things opportunities
as they make me nervous. Page 27 mention is one of the fine opportunities
ISI offers. All is as it usually somewhat is. The mass defections going
on at the moment are making people mildly odd (I think I mentioned that
eight to ten people are deserting). Having a hard time deciding where to
look for a house (and running out of time). Sandy's having a hard time
deciding what she wants to do in general (would you work for the LAPD?)
Let me know if you made any plans such that I should choose a different
arrival time.
-------
∂TO CSD.LENAT 13:23 28-Jul
RLL Mini-Tutorial
Doug -
Looks like Steve will be coming next week, circa Monday.
I plan to just give him an informal run thru (spending only, say,
part of Monday), and let him then attack his particular task.
I'll contact Jonathan King (now of HP) and have him sit in, if he wants.
I've not seen Greep recently, but he may want to join this ensemble also.
Do you want to give any blurbs, sales pitches, or what-not?
Shall I expose them to MRG, and his MRS? Time to make some color glossies?
Any comments, etc.?
Russ
∂28 Jul 1981 1450-PDT CSD.LENAT RLL DEMO/TUTORIAL
To: CSD.GREINER
No special presentation. Forget MRS -- do not strain their
minds needlessly.
Doug
∂28-Jul-81 1542 Steve Klein <SKLEIN at USC-ISIB> no = yes
To: RDG at SU-AI
is it to be presumptioned dat the plan of yesturdday iss acceptable?
you have a spare floor piece for a while by any chance?
∂29-Jul-81 1126 greep at RAND-UNIX Re: RLL Tutorial-ette
In-reply-to: Your message of 28 Jul 1981 1334-PDT.
Yes I'd like to observe.
Best mailbox (and one most often checked) is greep@SU-DSN. However,
the most reliable one (in terms of the machine being up) is greep@RAND-AI.
∂TO SKLEIN 15:26 29-Jul
No, no, no, ja, oui, no, si, cain, nein, lo, ...
Sure - I'll be busy both Sunday and Monday nights (dancing and Basketballing,
respectively). But come whenever.
(Unless you want a chaffeur service. Feel free to use my car if you
need a vehicle (it's manual transmission, if that makes a different).
Only I don't have all that much time...)
As to floor space: my landlord has some funny policies wrt guests
-- he doesn't especially like people in general, and visitors in particular.
So I'll not be able to supply even floor space, unfortunately. Perhaps
Tom could? Wasn't ISI going to store you in some fancy-smancy hotel, or
at least give you some allowance to reward you for braving the wiles of
perfunctory(sp) Palo Alto? If not, then it's not too surprising to hear
of a whole herd's defection from there...
Anyway, I still don't know quite what I'm going to do then. Probably
spend part of the first day completing a tour thru RLL's current set up;
and then let you loose.
If you've some particular thing you'd like to see demonstrated, let me
soon. Otherwise you'll get whatever mishmash seems appropriate to me;
and I've often been wrong in such decisions.
Some people: Jonathan King of HP and Steve Tepper (alias Greep [his choice])
will probably be in the audience as well, at least during the introductory
session.
By the way, did Ben contact you? He's on one of his periodic n-month vacations,
and is starting from LA. I gave him your name, number, address, ...
For symmetry,
Ben C. Moszkowski
(213) 477-2105 -- [Mother "L"ena] ?, Los Angeles, CA 900??
(213) ? -- [Father] 2567 S. Barryton Ave, Los Angeles, CA 90064
---
That's all for now. See you soon.
Russ
∂TO SKLEIN @ ISIB 12:43 31-Jul
tick, tick, tick, tick...
Steve -
So when should I expect you? And where? If you like, I can ask
for floor space for you. CS people with spare rooms include
Milt Grinberg - CSD.GRINBERG@SCORE
Mike Genesereth - CSD.GENESERETH@SCORE
See you soon,
Russ
∂31-Jul-81 1636 Steve Klein <SKLEIN at USC-ISIB> Re: tick, tick, tick, tick...
To: RDG at SU-AI
In-Reply-To: Your message of 31-Jul-81 1243-PDT
Russ--
Da Details: I'll be arriving there this Sunday a bit around 10:30pm. My
return is for the following Sunday at Noon. I have semi-room arrangements
(currently a hole for Tuesday nite--there seems to be a Chess tournament there)
and a vehicle, so no problems there...I'll get hold of you Sunday evening to
see what's next, unless you have alternative suggestions.
Steve.
-------
∂ 1 Aug 1981 2031-PDT GREINER RLL Demo
To: greep at RAND-UNIX, greep at SU-SCORE, jjk at SU-AI, stt at SU-AI
cc: greiNER
... will be held at 11 AM, this Monday morning; if all goes as planned.
(Steve's due to arrive the previous night.)
Please meet in my office - 251 Margaret Jacks.
Russ
-------
Messages with Jonathan King - HP
-- Mailed him the following messages:
∂06-Apr-81 1612 Steve Klein <SKLEIN at USC-ISIB> Re: Yak, Yak, Yak
∂01-May-81 1745 Steve Klein <SKLEIN at USC-ISIB> A Test of Wizardry
∂To SKLEIN@ISIB (18:11 20-May)
∂TO SKLEIN@USC-ISIB 16:43 22-June
-- real contacts:
∂TO JJK 15:43 24-Jul
Where it's at
Jonathan:
The file JJK[rdg,dbl] has some of my messages with Steve Klein --
I printed you a copy (left in the G mailbox); or feel free to examine it
on line.
Sorry it's so chatty -- Steve and I have known each other for 8 years now...
Russ
∂24-Jul-81 1732 JJK via SU-TIP
THANKS, I'LL PICK UP THE LISTING.
∂TO JJK 13:31 28-Jul
RLL Tutorial-ette
Jonathan:
Looks like Steve Klein, from ISI, will be coming next week,
circa Monday. I plan to just give him an informal run through of RLL,
(spending only, say, part of Monday),
and let him then attack his particular task.
Would you like to sit in on some of the seesions -- in particular
the first one?
The actual time is still up in the air. I'd prefer late morning,
around 11; but Steve may just be arriving then. Do you have any preferences?
Russ
Messages with Steve Tepper (Greep) - Rand, Stanford
∂TO GREEP@SCORE, GREEP@Rand-Unix 13:34 28-Jul
RLL Tutorial-ette
Steve -
Looks like Steve Klein, from ISI, will be coming next week,
circa Monday. I plan to just give him an informal run through of RLL,
(spending only, say, part of Monday),
and let him then attack his particular task.
Would you like to sit in on some of these sessions -- in particular
the first ones?
The actual time is still up in the air. I'd prefer late morning,
around 11; but Steve may just be arriving then. Do you have any preferences?
Russ
PS What is your prefered mailing address?
∂12 Aug 1981 14:45-PDT greep at RAND-UNIX Re: RLL Demo
To: GREINER at RAND-AI
In-reply-to: Your message of 1 Aug 1981 2031-PDT.
Sorry I never got back in the afternoon, got sucked into a meeting.
Am now shanghaied down in LA, back in a couple of weeks.
---------------
-------